Over 90% of the traffic in today's internet is so-called dissemination traffic, i.e. operations such as retrieving a website or downloading a video. In contrast to point-to-point connections (such as a voice over IP conversation), where the source and the destination address are essential parts of the communication, dissemination traffic has different characteristics. In many cases it is completely irrelevant who delivers the desired content, as long as it can be assured that the correct content is delivered (this can be verified for instance by cryptography such as a digital signature). Classical examples are a webpage or a video file.
Driven by this trend, the networking research community has lately started investigating so-called content-centric networks (compare V. Jacobson, M. Mosko, D. Smetters, and J. Garcia-Luna-Aceves, “Content-centric networking”, Whitepaper, Palo Alto Research Center, January 2007), also referred to as information-centric networks. A characteristic of such networks is that information objects become the first order elements in the network, i.e. already the routing layer is aware of the content that is transported. This opens the door to many optimizations not possible conventionally, such as optimized routing or transparent caching.
In the 4WARD project (compare http://www.4ward-project.eu), this scope has even been broadened, so that also the virtual representations of real-world objects (such as the Eiffel tower) and non-dissemination traffic (such as a voice call) shall be handled. The corresponding concept is referred to as Networks of Information, NetInf (compare C. Dannewitz, K. Pentikousis, R. Rembarz, E. Renault, O. Strandberg, and J. Ubillos, “Scenarios and research issues for a Network of Information”, In Proc. 4th Int. Mobile Multimedia Communications Conf., Oulu, Finland, July 2008).
A fundamental aspect of NetInf that influences the overall architecture is the identifier/locator split. In NetInf, the functional overloading of IP addresses acting as both identifiers and locators may be eliminated via a clean split of those two functions. Each information object (denoted e.g. by “Obj”) may have a locator (denoted e.g. by “LObj”) pointing at the location of the information object in the network and a separate identifier (denoted e.g. by “IDObj”), enabling the persistent identification of the information object regardless of possible location changes or replication in the network of information. In order to make this system work, the bindings and indirections between the different objects need to be handled efficiently; this task is carried out by a Name Resolving (NR, Name Resolver/Name Resolution) entity.
In the context of this application, the term “network of information” (NetInf) may hence particularly denote a communication network in which a plurality of communicatively coupled nodes are provided and which is based on an information-centric architecture in which a provisioning of information objects is possible based on an identity, ID, identifying a specific information object unambiguously (for example uniquely) in the network of information and based on a locator, L, specifying a location of the network of information at which the specific information object is available. An identifier of an information object can be used for identifying an information object during communication of different nodes of a network of information and can be used for distinguishing between an information object and other information objects. A locator, sometimes also known as “location pointing information” points at a location (such as a node capable of providing specific data) of an information object in a network of information. An example for a locator is a data block serving as an address of a node at which the corresponding information object is available. Such an address may be for instance an Internet Protocol (IP) address being a numerical identification (logical address) that can be assigned to devices participating in a computer network utilizing the Internet Protocol for communication between its nodes. A locator may provide a link to a node at which a specific information object is available for download. In other words, a locator may be considered as an address at which a corresponding information object can be accessed at.
A network of information may involve wired and/or wireless communication between the various nodes. A network of information is also called content-centric network or information-centric network. A locator points at a location of a data object in a network, for instance it denotes a network address, for example an IP address.
The term “node” may particularly denote a communication entity which may be configured for communication with one or more other communication entities in a network. For instance, such a node may be a user equipment to be operated by a user and to be coupled to a communication network. Examples are mobile phones, laptops or personal computers, data cards for plugging or on-board integration into laptops or personal computers, personal digital assistants (PDAs), navigation systems, etc. Hence, mobile (for example portable) or stationary communication devices can be operated in accordance with an corresponding communication architecture. For instance, such a communication device may be used in the context of telecommunications.
The term “information object” may particularly denote a set of data representing information content or use data (for instance text such as a database or a story or an article, or multimedia content such as music data, video data, or any other information related to a service or an application) which can be requested by one node and provided by another node communicatively coupled to one another in a network of information. Such an information object may be characterized for communication purposes by an information object identity in combination with corresponding location pointing information.
The term “resolving node” (sometimes also known as “resolution node”) may particularly denote a name resolver node in a network of information. A publishing initiation node may provide the resolving node with one or more locators regarding a corresponding information object. The latter can be provided by the publishing initiation node upon request of a client node (which may also be denoted as an information object requesting node). Hence, a resolving node may manage or handle data blocks each of which including an indication at which location or node of a network of information an information object or other piece of data is available. Such a resolving node may be configured for receiving such data blocks from a publishing initiation node offering a corresponding service and may be configured for transmitting such data blocks to a client node requesting a corresponding service.
The term “publishing initiation node” may particularly denote a node in a network of information which node can indicate to the resolving node an information object in conjunction with an assigned locator and may therefore indicate which information object is available where in a network. The publishing initiation node may be at the same time the provider of a corresponding information object itself or may be another communication entity.
The term “client node” (or “information object requesting node”) may particularly denote a node in a network of information which node may search for a location of a specific information object in a network of information. For this purpose, the client node may initiate sending of a query to a resolving node and may ask the latter for a location of a node offering a corresponding service of providing the desired information object.
The term “gateway node” may particularly denote a network node equipped for interfacing between two networks, for instance that differ regarding security requirements and/or regarding different protocols.
The term “routing node” may particularly denote a node that forwards data packets between networks or between different nodes of a network.
Now referring to FIG. 2, in order make an information object 220 known in the network, it has to be published by a publishing initiation node 210. As illustrated in FIG. 2, this is done by sending a PUBLISH message to a resolving node (or Name Resolver (NR)) 200 stating that the information object Obj 220 designated by the identifier IDObj is available at the network location 210 designated by LObj. LObj can also be a list of locations. If the information object Obj 220 has already been published before, the additional location is added to the database or an existing entry is updated in the database, if this is the first registration, a new entry is created.
FIG. 3 illustrates the process of retrieving an information object Obj 220 from the NetInf network. As outlined above, a network of information allows a user to request access to an information object Obj 220 based on an identifier IDObj regardless from which location the information object 220 will be provided. The identifier IDObj may be obtained, for instance via a link in an email or via a search operation.
Consequently, firstly a client node 230 (functioning as an information object requesting node) resolves the identifier IDObj of the object 220 into its locator LObj. A RESOLVE message (step 1) comprising the identifier IDObj is sent to resolving node 200 which can look-up a locator LObj corresponding to the identifier IDObj. The locator LObj pointing to a location 210 where the information object Obj 220 can be obtained from is subsequently sent from the resolving node 200 to the client node 230 in step 2 in FIG. 3. In FIG. 3, the client node 230 comprises a name resolving client (NRC) 250 located on the client node 230 itself for the resolving. After the locator LObj is known to the client node 230, the client node 230 can proceed and retrieve the information object Obj 220 from the actual storage location identified by the locator LObj. Client node 230 can send a request message GET for requesting the information object Obj 220 with identifier IDObj to a node 210 identified by locator LObj. The node 210 can then obtain, e.g. from an own storage, the information object Obj 220 corresponding to the identifier IDObj and send the information object Obj 220 to the client node 230.
While the former case is more likely to be used when NetInf is deployed as an overlay to IP, native NetInf-enable networks also make it possible to handle the name resolving in the network, i.e. by the NetInf aware routing node(s) which contact the resolving node 200 and request a storage location denoted by a locator.
As illustrated in FIG. 4, this can for instance be realized by an NRC entity 250 present on a first hop router (FHR) 240. The request can then—as in the above example—be routed to the storage location.
Once a client node 230 has retrieved an information object, it can optionally be published again with the location of the client node 230, similar as in peer-to-peer networks. Optional encryption ensures that only authorized parties can access the actual data. Otherwise, the intention is to enable data to “roam around freely” in order to support replication, caching and other optimizations.
As can be taken from FIG. 5, today's Internet is strictly separated from private domains (secured network or private network, PN) such as a company network. Firewalls and gateway nodes ensure that attacks are not possible from the outside, and that private information does not leave the network.
In NetInf networks, these separations do not exist anymore. All information objects (including private information objects) are located in the Network of Information and can be addressed and accessed from any user via the NetInf control (more specifically: the location of every information object can be resolved using the common name resolving (NR) system and afterwards the information object can be retrieved from the resolved location). It is in many cases assumed that strong encryption of the information object is sufficient to protect private data by only being decodable by an authorized subset of the users, leading to a “virtual partitioning” of the network, as illustrated in FIG. 6.
Companies, government agencies and other stakeholders are unlikely to rely on virtual partitioning by encrypting objects as the only way of controlling and enforcing access to their data, as this will, for instance, put an enormous burden on the key management. In many cases, a strict partitioning of the network may be desired and necessary for trust reasons and to ensure that information with different confidentiality requirements and of different confidentiality levels is properly separated. This is necessary, for instance, for isolating confidential company-internal information from the rest of the Network of Information.